• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    A client processing device used in a client / server computing system that performs transactions, the device comprising means for issuing a start command to signal the start of a transaction, and the transaction to be started. Means for sending a command to an object in a remote server that has a transaction context having a specific value indicating that transaction objects that have been created but representing the transaction have not yet been created; When created, it has a means for receiving a modified transaction context from the remote server.
    公开号:KR20010042008A
    申请号:KR1020007010339
    申请日:1998-12-18
    公开日:2001-05-25
    发明作者:체셀아만다엘리자베스；월캐서린사라
    申请人:포만 제프리 엘；인터내셔널 비지네스 머신즈 코포레이션；
    IPC主号:
    专利说明:

    A client / server computing device, method and computer program product with a location of a transaction object that the client can select.
    Client / server computing has become increasingly important in the information technology world over the last few years. This type of distributed computing allows one machine to delegate some of its work to another machine, for example, perhaps more suitable for performing that work. For example, while the client is simply a desktop personal computer (PC) that requests information from a database and uses it in one of the local programs, the server handles the storage of vast amounts of data. It can be a high performance computer running a program.
    The benefits of client / server computing have been further enhanced by the use of well-known computer programming techniques called object-oriented programming (OOP), which is a "platforms" where the client and server are different (heterogeneous). Enable to be located at A platform is a combination of specific hardware / software / operating system / communication protocols that a machine uses to perform a task. OOP allows client application programs and server application programs to run on their own platform without worrying about how client application work requests are communicated and accepted by the server application. As such, the server application need not worry about how the OOP system receives and translates the processing results of the server application and retransmits it to the requesting client application.
    Details of how OOP technology is integrated into heterogeneous client / server systems can be found in US Patent No. 5,440, 744 and European Patent Publication No. It is described in EP 0 677,943 A2. Both documents are incorporated herein by reference. However, examples of the basic structure will be given below for contextual understanding of the present invention environment.
    As shown in FIG. 1, client computer 10 (which may be a personal computer with an IBM OS / 2 operating system, for example) has an application program 40 running on its operating system. ("IBM" and "OS / 2" are trademarks of International Business Machines Corporation.) The application program 40 will periodically need data to be returned from the server 20 for work to be performed at the server computer 20 and / or subsequent use by the application program 40. For example, the server computer 20 may be a high performance mainframe computer running on IBM's MVS operating system (“MVS” is also a trademark of IBM Corp.). For the purposes of the present invention, whether a request for a communication service to be performed by the server is generated by user interaction with the first application program 40 or whether the application program 40 is independent of user interaction. It is irrelevant whether it operates and requests automatically during execution of the program.
    When the client computer 10 wishes to request a service of the server computer 20, the first application program 40 informs the first logic means 50 of the requested service. This is done, for example, by sending the name of the remote processing to the first logical means along with a list of input and output parameters. The first logical means 50 then processes the task of establishing the necessary communication with the second computer 20 with reference to the definition of available communication services stored in the storage device 60. All possible services are defined in the cohesive framework of the object class 70, which is derived from one object class. Service definition in this way has many advantages in terms of performance and reusability.
    In order to establish the necessary communication with the server 20, the first logical means 50 determines which object class in the framework needs to be used, and then at the server of the object An instance, that is, sent to the object, generates a message that causes the object to invoke one of its methods. This results in the establishment of a connection with the server computer 20 via the connecting means 80 and subsequent transmission of the request to the second logical means 90.
    The second logical means 90 then sends the request to a second application program 100 (hereinafter referred to as a service application) that is executed on the server computer 20 so that the service application 100 sends data. Enables you to perform specific tasks required by the request, such as executing a search procedure. Once this is done the service application will have to return the result to the first computer 10. The server application 100 interacts with the second logic means 90 during the performance of the requested task and when a result is returned to the first computer 10. When requested by the server application 100 and when the object instance is created from the cohesive framework of the object class stored in the storage device 110, the second logical means 90 retrieves instances of the object. Establish and call the appropriate method of this object.
    Using this method, the client application program 40 is not exposed to the communication structure. Moreover, the server application 100 is called through the standard mechanism for this environment. The server application does not know to be called remotely.
    The Object Management Group (OMG) is an international association of organizations involved in client / server computing of various aspects of heterogeneous platforms with distributed objects as shown in FIG. OMG has published an open standard for communicating (in OOP form) with a server machine (eg 20) by a client computer (eg 10). As part of this standard, an Object Request Broker (CORBA) has been defined, which provides an object-oriented bridge between the client and the server machine. The ORB separates client and server applications from object-oriented execution details that perform at least some of the work of the first and second logical means 50, 90 as well as the connecting means 80.
    As part of the CORBA software architecture, OMG has published a standard relating to "transactions", which is known as OTS, or Object Transaction Service. See, for example, the CORBA Object Transaction Service Specification 1.0, OMG Document 94.8.4. Computer-implemented transaction processing systems are used to perform critical business tasks in many industries. A transaction defines a unit of work that must be completely completed or completely removed without working. For example, in a bank automated machine where a customer withdraws money, withdrawing money, reducing the balance of money in the machine, and reducing the customer's deposit balance must all occur together or not at all. . Failure of one of the subordinate operations results in inconsistency between recording and actual occurrence.
    Distributed transaction processing includes transactions that affect resources at one or more physical or logical locations. In the example above, the transaction affects not only the bank balance managed by the bank's main computer, but also the resources managed by the local automation device. Such a transaction includes one particular client computer (eg, 10) that communicates with one particular server computer (eg, 20) through a series of client requests processed by the server. OMG's OTS is responsible for coordinating this distributed transaction.
    Typically, an application running in a client process initiates a transaction that will involve calls from a number of different servers, each of which transforms the local database by starting the server process according to the instructions contained in the transaction. The transaction executes the transaction (and therefore all servers complete the change in their local database) or aborts the transaction (thus all the servers "rollback", i.e., ignore the change in their local database.) To end. In order to communicate with the server during a transaction (eg, to instruct the server to perform or ignore its portion of the transaction), one of the processes involved must maintain state data for the transaction. This usually involves a process of starting a series of transaction objects, one of which is a coordinator object that coordinates the transaction according to various servers.
    A typical implementation of the OTS included in the Component Broker Series (trademark of IBM Corp.) product developed by International Business Machine Corporation and published in May 1997 is shown in FIG. The client process 21 that wishes to start a transaction (eg withdraw money from a bank account) needs to place a process that can create and maintain a transaction object that will maintain the state of the transaction. Since the current trend is to create "thin" clients (and therefore have minimal functionality), the client process 21 will typically not be able to maintain the transactional object locally and will create a server process suitable for this purpose. Should find
    In accordance with this prior art approach, OTS (or other services, such as CORBA Lifecycle Services) deploys server processes and places them on a deployed server process (Coordinator, Control, and Terminator). Create a transaction object (221) (including the object). The same server process (server A process 22 in FIG. 2) is always selected according to this prior art. When deploying the server A process 22, the client process 21 sends a message to the server A process 22 (arrow of number 1 enclosed in a circle) so that the server A process 22 sends the transaction object 221. Command to create Server A process 22 then creates a transaction object 221 and sends a response to the client 21 containing the transaction context (circled by the number 2 arrow). The client 21 then sends a debit bank account command to the server B process 23 (the process that includes the bank account object 231 to which the client process 21 attempts to withdraw money). Arrow of the number 3). This later command involves the transaction context provided to the client 21 by the server A process 22. In this way bank account object 231 in process 23 registers itself with transaction object 221 in process 22 so that bank account object 231 is performed by transaction object 221 at the end of the transaction, or Allows the user to be commanded to roll back (the number 5 arrow in a circle).
    This implementation is inefficient in at least two respects. First, because the same server process is always used when a client deploys a remote process to create and maintain a transaction object, the server process is soon overloaded, thus making its work (e.g., updating the contents of a local resource). Can not be performed efficiently. Second, many cross process flows exist between the various processes involved in the transaction. Even if transaction objects are created and maintained on a random server, the problem of a large number of cross-process calls still exists.
    Moreover, this implementation gives the client no choice as to which server will be used to deploy the transaction object. The client attempts to start the transaction object, calls the factory's creation method, and finally calls the CosTransaction :: Current :: resume () method to "current" the transaction. You can try to find a transaction factory (CosTransaction :: TransactionFactory) on the server you want to state, but this involves a lot of processing steps on the part of the client. It would be much easier if the client uses a much simpler CosTransactions :: Current interface and can still choose a server to place the transaction object. But the current state of the art does not make this possible.
    Summary of the Invention
    According to a first aspect, the present invention provides a client processing device for use in a client / server computing system that performs a transaction, the device comprising means for issuing a start command to signal the start of a transaction and an object in a remote server. Means for sending a command including a transaction context with a particular value indicating that a transaction has started but that transaction objects representing the transaction have not yet been created, and once the remote server has created the transaction object; Means for receiving the modified transaction context from the server.
    Preferably, the specific value is a null value. Advantageously, the client processing apparatus further comprises means for selecting a remote server that is determined to be most suitable for creating said transaction object, wherein means for sending a command to an object in the remote server selected by said selection means. Send the command. Preferably, the selection means determines which remote server has the updated resources in the transaction and selects this remote server as the most suitable server for creating the transaction object.
    In one embodiment of the invention, the sending means sends a command to a dummy business object, and in another embodiment the sending means sends a command corresponding to a dummy method on the object.
    According to a second aspect, the present invention provides a server processing apparatus for use in a client / server computing system that performs a transaction, the apparatus comprising means for receiving instructions from a client directed to an object located at the server processing apparatus—the instructions Includes a transaction context having a specific value indicating that a transaction has been initiated by the client but that the transaction objects representing the transaction have not yet been created, and recognizes the specific value within the transaction context and responds to the specific value. Thereby creating the transaction objects locally.
    According to a third aspect, the present invention provides a method for performing the functions of the client described in the first aspect.
    According to a fourth aspect, the present invention provides a method for performing the functions of the server described in the second aspect.
    According to a fifth aspect, the present invention provides a computer program product for performing the functions of the first aspect when executed in a computer.
    According to a sixth aspect, the invention provides a computer program product for performing the functions of the second aspect when executed on a computer.
    Since the client can easily select the server on which the transaction object is created, for example, such an object can be selected to be created within a server process that will be substantially involved in performing the transaction (eg, Resources), and the number of cross process flows is greatly reduced. This can be clearly seen by a simple comparison between Fig. 2 (prior art) and Fig. 3 (preferred embodiment of the present invention). 3 has only two cross process calls, while FIG. 2 has five cross process calls.
    The present invention refers to a client / server (also referred to as " distributed ") in which one computing device (the client) requests another computing device (the server) to perform some of the client's work. Known). The client and server may also be located on the same physical computing device.
    The invention will be better understood by the description of the preferred embodiment below which will be read with reference to the drawings below.
    1 is a block diagram of a well known heterogeneous client / server architecture utilizing object methods in the context in which preferred embodiments of the present invention may be applied.
    2 is a block diagram illustrating a cumulative OTS implementation.
    3 is a block diagram illustrating an OTS implementation in accordance with a preferred embodiment of the present invention.
    4 is a flow chart showing the steps that occur when a client issues a start command in accordance with the OTS implementation of FIG.
    5 is a block diagram illustrating an OTS implementation in accordance with a preferred embodiment of the present invention.
    6 is a block diagram illustrating a server process according to a preferred embodiment of the present invention.
    The Common Object Request Broker (CORBA) Object Transaction Service (OTS) is called "Current" with a "begin" method used by a client application program (source code) to signal the start of a transaction. Provide a known interface object to the underlying software layer. In accordance with a preferred embodiment of the present invention, when a client application is created or performed on a particular client architecture and includes the "begin" method, the underlying software proceeds accordingly and is a transaction in the server that is significantly involved in the transaction. You will create a transaction by starting a state object (for example, a server with server resources involved in the transaction).
    In a preferred embodiment of the present invention, an application running in the client process 31 (see FIG. 3) initiates a transaction by calling the "begin" method of the Current interface object as usual. The client process then records that it issued this command, for example by creating a minimum set of objects locally. The operation is described in step 41 of the flowchart of FIG. In the example of this description, it will be assumed that the transaction performed is the withdrawal of money from a bank account, a common transaction process performed worldwide, using an automated teller machine (ATM) as a client every day.
    It should be noted that at this stage in the prior art a remote process 22 is deployed, and a transaction object (221 of FIG. 2) has been created within the remote process 22. As described below, the present invention delays the creation of this transaction object until later.
    The application running in the client process 31 then issues a debit command to the bank account object 331 in the server B process 33 as the first substantial part of the withdrawal transaction. In this example, the debit command is the first remote flow made by a client process after issuing the "begin" command within a transaction. When creating this command, the client process includes some transaction context in the command to allow the bank account object 331 to know that the command is part of a transaction and to confirm a particular transaction.
    In the prior art (FIG. 2), the client process 21 has received the transaction context from a transaction object 221 started within a remote process 22. However, in the preferred embodiment of the present invention, the transaction object has not yet been created and thus cannot provide a transaction context to the client process. Thus, in the preferred embodiment, when the client process 31 sends a debit command to the bank account object 331 in the remote process 33, a specific transaction context (eg, null transaction context) is included in the command. (The arrow of the number 1 surrounded by a circle in FIG. 3). A null transaction context means that all fields of the transaction context are set to zero. This particular transaction context indicates that the transaction has started but the transaction object has not yet been created. This latter operation is described in step 42 of the flowchart of FIG.
    When server B process 33 is aware of this particular transaction context (eg a null transaction context), it is informed that the transaction has started but no transaction objects have yet been created. Server B process 33 then locally creates transaction objects 332 (step 43). Since transaction objects 332 have been created, the transaction now has a valid transaction context and this valid transaction context is assigned to the transaction. The Server B process then sends a response (the arrow of the number 2 enclosed in a circle) to the client process 31 to inform the client process 31 of the valid transaction context (step 44 in FIG. 4). The client process now has full information of the created transaction.
    At this stage, the bank account object 331 communicates in the usual way with the transaction object 332, except that all such communication takes place within the same processor and thus no cross-process flow is required for such communication ( Step 45). In the given example, the communication that occurs includes a bank account object 331 that registers a transaction object 332, and when the transaction ends, the transaction object 332 issues an execute or rollback command to the bank account object. Send to 331.
    The client will call other servers to join the transaction, which must register the transaction objects created within the Server B process resulting in some cross-process flow between the servers. However, at least the use of the present invention by the client minimizes the total number of cross process flows because the interaction between local resources and transaction objects in the Server B process does not result in any cross process flow. Also for a transaction involving only one server process, the only cross process flow that exists would be between the client process and this one server processor.
    In another embodiment, the Server B process 33 may later create transaction objects, for example, during resource registration rather than the moment a null transaction context enters the Server B process 33. do.
    While a null transaction context (all fields set to 0) is used in the described embodiment, other specific values of the transaction context may also be used. For example, the private data field of the transaction context may be set to a specific value.
    The above describes IBM's enhancements to the original Component Broker Series product described in Figure 2, which results in the intelligent placement of transaction objects on the first server process invoked in a transaction. This enhancement is described in IBM's co-pending UK patent application 9800830.3, filed January 6, 1998. However, there are many transactions that would not be most useful for creating transaction objects within the first server process to be invoked.
    For example, suppose the first call in a transaction is an authentication call to an authentication business object for the purpose of authenticating the client's identity (eg, granting the client permission to perform this type of transaction). To make sure you received). The placement of transactional objects within the subprocess containing this business object will not reduce the number of cross process flows since this server process does not have a business object representing the resource updated in the transaction. In other words, if a transaction object was created in this server process with an authentication business object, many cross-process flows would be required at the end of the transaction because all business objects representing resources updated during the transaction would exist in other server processes.
    Another example is when the first call to a business object in a transaction is a read-only call to a business object representing a resource. For example, the first call in a transaction only requires reading the value of the bank account balance, not updating any value in the business object representing the bank account resource. In other words, in this case it is not desirable to create a transaction object in the server process that contains this business object.
    The present invention has evolved to give the client more control over which server process is selected to create a transaction object, and the description of the preferred embodiment will now continue in view of explaining this added functionality.
    In FIG. 5, the client process 51 is commanding the processing of a transaction. The first call to a remote server process in a transaction is a call to an authentication business object 531 in server B process 53 for authenticating client 51. The second call to a remote process in a transaction is simply a call to a bank account object 521 in server A process 52 to read the value of the bank account balance. The third call to a remote process in the transaction is a call to the bank account object 541 in the server C process 54 to affect the withdrawal of funds by reducing the value of the balance of this bank account.
    In the transaction described above, it would be undesirable to create transaction objects in server A process 52 or server B process 53 because there are no business objects located in those processes that represent updated resources in the transaction. Server C process 54 is a process with a bank account object 541 updated in a transaction, so it would be highly desirable to create transaction objects in server C process 54.
    The preferred embodiment of the present invention places dummy business objects 522, 532, 542 in server processes 52, 53, 54, respectively. These dummy business objects are each given a well known key (eg, generated from a server name) so that the client 51 can easily place any dummy business object. While inheriting from CosTransactions :: Transactional objects, the dummy business objects may be given any type of functionality. Their purpose is to provide an easily accessible object located on each of the multiple servers so that the client can choose one of the servers as the location of the transaction object. The client 51 ensures that the first call to a remote process in the transaction is a call to a dummy business object in the server process that the client wishes to create transaction objects for. If the dummy business object is located in a server, that server is a candidate for choice of placement of the transaction object by the client.
    For example, using the example given above in FIG. 5, the first two calls of the client's transaction are calls to the authentication business object 531 of process 53 and the bank account object 521 of process 52. . However, the client process 51 transforms the transaction such that the first remote call (made to occur before these two calls) is a call to the dummy business object 542 in the server C process 54, which is in the transaction. Is the place where the bank account object 541 to be updated at will be located, and therefore the best process to locate the transaction object.
    Thus, as shown in FIG. 5, the client process 51 makes a first call to the dummy business object 542 in the server C process 54 (arrow of number 1 enclosed by a circle). This corresponds to step 42 of FIG. 4, but the client sends a call with a null transaction context to the dummy business object 542 rather than the bank account object. The sole purpose of this call is to start a transaction object 543 in the server C process 54 (see FIG. 6). The dummy business object is aware of the null transaction context in this first call from the client and continues to create a transaction object in response to this acknowledgment (this corresponds to step 43). Secondly, the client process authenticates the client by making a second call (the arrow of the number 2 enclosed in a circle) to the authentication business object 531 in the server B process 53. Thirdly, the client process makes a third call to the bank account object 521 in the server A process 52 to read the balance of this bank account (arrow of number 3 surrounded by a circle). Fourth, the client process makes a fourth call to the bank account object 541 in the Server C process (arrow of number 4 surrounded by a circle) to reduce the balance of this account (money is withdrawn from here). ).
    Once the server B process 53 locally creates a transaction object, the process 53 responds to the client in a valid transaction context (this corresponds to step 44).
    Thus, the preferred embodiment of the present invention looks at the transaction that is about to be executed, determines which server process is best suited for placing the transaction object, and at the beginning of the transaction to a dummy business object located within the determined server process. Contains the client that adds the call. This causes the transaction object to be created in this determined server process.
    In the second embodiment, dummy business objects are not used. Instead, a dummy method is called on an existing object (eg, bank account object 541). Thus, in this second embodiment, the first call in the example of FIG. 5 calls a dummy method of the object 541 (eg, bankaccount.hello ()), from the bank process from the client process 51. There will be a call to an object 541, which causes the transaction object to be created within the server process where the bank account object 541 is located.
    权利要求:
    Claims (15)
    [1" claim-type="Currently amended] A client processing device used in a client / server computing system that performs transactions,
    Means for issuing a start command to signal the start of a transaction,
    Means for sending a command to an object in the remote server that includes a transaction context having a specific value indicating that a transaction has been started but transaction objects representing the transaction have not yet been created;
    Means for receiving a modified transaction context from the remote server once the remote server creates the transaction objects.
    [2" claim-type="Currently amended] The method of claim 1,
    And the specific value is a null value.
    [3" claim-type="Currently amended] The method of claim 1,
    The client processing apparatus further comprises means for selecting a remote server determined to be most suitable for creating the transaction objects, wherein the means for sending the command sends the command to an object in the remote server selected by the selection means. Client processing device.
    [4" claim-type="Currently amended] The method of claim 3, wherein
    And said selecting means determines which remote server has updated resources in said transaction and selects this remote server as the server most suitable for creating said transaction object.
    [5" claim-type="Currently amended] The method of claim 1,
    And said sending means sends a command to a dummy business object.
    [6" claim-type="Currently amended] The method of claim 1,
    The transmitting means is a device for transmitting a command corresponding to a dummy method of the object.
    [7" claim-type="Currently amended] A server processing apparatus used in a client / server computing system for performing a transaction, the server processing apparatus comprising: means for receiving a command from a client directed to an object located within the server processing apparatus, wherein the instruction is indicative of the transaction although the transaction has been initiated by the client. Contains a transaction context with a specific value indicating that the transaction objects have not been created yet;
    Means for recognizing the specific value within the transaction context and for locally creating the transaction objects in response to the specific value.
    [8" claim-type="Currently amended] The method of claim 7, wherein
    And said particular value is a null value.
    [9" claim-type="Currently amended] The method of claim 7, wherein
    And the apparatus further comprises means for registering a local resource associated with a transaction with the locally created transaction object.
    [10" claim-type="Currently amended] The method of claim 7, wherein
    And the means for receiving receives a command on a dummy business object located within the server processing apparatus.
    [11" claim-type="Currently amended] The method of claim 7, wherein
    And the means for receiving receives a command corresponding to a dummy method on an object located within the server processing device.
    [12" claim-type="Currently amended] A client processing method used in a client / server computing system for performing a transaction,
    Issuing a start command to signal the start of a transaction;
    Sending a command to an object in the remote server including a transaction context having a specific value indicating that the transaction has started but that transaction objects representing the transaction have not yet been created;
    Receiving a modified transaction context from the remote server once the remote server creates the transaction objects.
    [13" claim-type="Currently amended] A server processing method used in a client / server computing system for performing a transaction, the method comprising: receiving a command from a client directed to an object located in the server processing device, wherein the command indicates the transaction has been initiated by the client; Contains a transaction context with a specific value indicating that the transaction objects have not been created yet;
    Recognizing the particular value in the transaction context and locally creating the transaction objects in response to the particular value.
    [14" claim-type="Currently amended] A computer program product stored on a computer readable storage medium that performs a client processing method used in a client / server computing system that executes a transaction when executed on a computer, the method comprising issuing a startup command to issue a transaction. To announce the beginning,
    Sending a command to an object in the remote server including a transaction context having a specific value indicating that the transaction has started but that transaction objects representing the transaction have not yet been created;
    Receiving a modified transaction context from the remote server once the remote server creates the transaction objects.
    [15" claim-type="Currently amended] A computer program product stored in a computer readable storage medium for performing a server processing method used in a client / server computing system that executes a transaction when executed on a computer, the method comprising: Receiving a command directed to a located object, the command receiving a command by the client including a transaction context having a specific value indicating that a transaction has been started but transaction objects representing the transaction have not yet been created; Wow,
    Recognizing the particular value in the transaction context and locally creating the transaction objects in response to the particular value.
    类似技术:
    公开号 | 公开日 | 专利标题
    US8463761B2|2013-06-11|Decentralized, distributed internet data management
    Beugnard et al.1999|Making components contract aware
    US6148323A|2000-11-14|System and method for managing the execution of system management
    US6189046B1|2001-02-13|Mechanism and method for merging cached location information in a distributed object environment
    US6275863B1|2001-08-14|System and method for programming and executing long running transactions
    US7281050B2|2007-10-09|Distributed token manager with transactional properties
    US5787251A|1998-07-28|Method and apparatus for subcontracts in distributed processing systems
    EP0501610B1|1999-03-17|Object oriented distributed computing system
    US6513056B1|2003-01-28|System and method for efficiently synchronizing cache and persistant data in an object oriented transaction processing system
    US6446204B1|2002-09-03|Method and apparatus for implementing an extensible authentication mechanism in a web application server
    US6282581B1|2001-08-28|Mechanism for resource allocation and for dispatching incoming calls in a distributed object environment
    US5848273A|1998-12-08|Method for generating OLE automation and IDL interfaces from metadata information
    US6728788B1|2004-04-27|Method and system for converting a remote procedure call to a local procedure call when the service is on the same device as the calling client
    US7735097B2|2010-06-08|Method and system to implement a deploy service to perform deployment services to extend and enhance functionalities of deployed applications
    US7739657B2|2010-06-15|Pipeline architecture for use with net-centric application program architectures
    US7093247B2|2006-08-15|Installation of a data processing solution
    US6233585B1|2001-05-15|Isolation levels and compensating transactions in an information system
    US6260077B1|2001-07-10|Method, apparatus and program product for interfacing a multi-threaded, client-based API to a single-threaded, server-based API
    US7721283B2|2010-05-18|Deploying a variety of containers in a Java 2 enterprise edition-based architecture
    JP3518958B2|2004-04-12|Distributed file system translator with extended attribute support
    Yang et al.1996|CORBA: a platform for distributed object computing
    US6094688A|2000-07-25|Modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources
    US6157927A|2000-12-05|Methods and apparatus for enabling a component in a first transaction processing environment to access a resource in another environment that is under the control of an Xatmi complaint transaction manager
    US7089317B2|2006-08-08|Architecture for plugging messaging systems into an application server
    US6832238B1|2004-12-14|Local transaction management
    同族专利:
    公开号 | 公开日
    KR100404786B1|2003-11-07|
    CN100377090C|2008-03-26|
    DE69814697D1|2003-06-18|
    PL193051B1|2007-01-31|
    DE69814697T2|2004-04-08|
    JP3579353B2|2004-10-20|
    US6374283B1|2002-04-16|
    IL135479A|2003-11-23|
    GB9806779D0|1998-05-27|
    PL343101A1|2001-07-30|
    IL135479D0|2001-05-20|
    CN1290362A|2001-04-04|
    EP1068571A1|2001-01-17|
    JP2002510084A|2002-04-02|
    EP1068571B1|2003-05-14|
    WO1999050745A1|1999-10-07|
    GB2336006A|1999-10-06|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    法律状态:
    1998-03-31|Priority to GB9806779.6
    1998-03-31|Priority to GB9806779A
    1998-12-18|Application filed by 포만 제프리 엘, 인터내셔널 비지네스 머신즈 코포레이션
    2001-05-25|Publication of KR20010042008A
    2003-11-07|Application granted
    2003-11-07|Publication of KR100404786B1
    优先权:
    申请号 | 申请日 | 专利标题
    GB9806779.6|1998-03-31|
    GB9806779A|GB2336006A|1998-03-31|1998-03-31|Client/server computing with client selectable location of transaction objects|
    [返回顶部]